Formal Development for Railway Signaling Using Commercial Tools

This report presents the approach experimented by a railway signaling manufacturer for the development of applications through Simulink/Stateflow in a standard–regulated industrial framework. The General Electric Transportation Systems (GETS) railway signaling division of Florence, inside a long-term effort of introducing formal methods to enforce product safety, decided to adopt the Simulink/Stateflow tool-suite to exploit model based development and code generation within its own development process [1]. Products traditionally provided by GETS, like any railway signaling application developed for Europe, shall comply with the CENELEC norms [2]. Introducing the Simulink/Stateflow tool-suite within a CENELEC based process is not a straightforward step, and GETS faced two crucial obstacles: the lack of a formal semantics for the Simulink/Stateflow languages, and the absence of a CENELEC compliant code generator. The languages used by Simulink and Stateflow are not formally specified and their semantics is essentially given by the simulation engine itself. This increases the difficulty of defining an effective formal verification strategy, a highly recommended practice according to the CENELEC norms. Code generators provided for the tool-suite (in particular Stateflow Coder) are not certified for railway software development, this complicating their adoption in this domain. In order to overcome these problems, GETS first introduced a set of modeling guidelines to restrain the semantics of the tools [3]. The idea is based on the intuition that reducing the Simulink/Stateflow languages to a semantically unambiguous subset enables proper code synthesis and formal verification. Once developed this set of modeling rules, a proper strategy including formal development, model based unit testing and formal verification of modules has been defined. Given a set of system-level functional requirements, these can be partitioned into separate sets of unit requirements and then formalized into Stateflow models according to the GETS guidelines. Each model represents an independently verifiable system component. Unit testing based on requirement coverage is then performed on the models through the Simulink environment, and during test execution a test observer is used to register the test-suite input data and the test results. The registered test-suite is executed on the auto-coded unit and results are automatically compared. Finally, the unit is analyzed through